Tableauで作ったダッシュボードが遅い時にチェックする30のポイント #tableau
はじめに
どうも。DI部@大阪オフィスのtamaです。
上記の記事は、Tableauで作成したダッシュボードのパフォーマンスを上げるためのポイントを30個紹介しています。今回はこれを参考に、Tableauダッシュボードのパフォーマンスに関するTipsを紹介したいと思います。
下記のホワイトペーパーも参考にしております。
こちらもあわせてどうぞ。
30のチェックポイント
一般的に効果が大きいと思われる順に並んでいます。とはいえ、環境に応じて何が一番パフォーマンス向上につながるかは変わるので、順番はあくまで参考程度にしましょう。
1. Tableau Desktop上でデータ前処理を行っている場合、前処理部分をTableau Prepに移すことを検討する
「ダッシュボードが遅い」と思ったら、真っ先に「Desktop上でデータ前処理（に関する計算）を行っていないか」を確認してください。そういった計算が多ければ多いほどダッシュボードのパフォーマンスは落ちます。
そういった計算は全部Tableau Prepで先に済ませてしまいましょう。Tableau Desktopはビジュアライズ処理のみ行うようにすれば、パフォーマンスは向上します。Tableau PrepはTableau Desktopを持ってる人には無料でついてくるので、ぜひ使いましょう。
2. 必要に応じて抽出を使用する（場合によっては「複数の表」オプションを使用することを検討する）
「抽出」はTableau専用のファイル形式であり、Tableauが一番パフォーマンスを発揮できるため、抽出を使用しても問題ないのであれば（絶対ライブ接続じゃないとダメ…とかじゃなければ）、迷わず抽出を使用しましょう。
「単一の表」と「複数の表」
複数テーブルを（結合などして）一気に抽出する場合、2つのオプションがあります。デフォルトは「単一の表」となっており、これは全部結合した状態で抽出ファイルを作成します。これに対して「複数の表」は抽出作成時は結合しません（個々のテーブル毎に抽出する）。ですので、抽出作成時は「複数の表」の方が速い可能性があります。しかし、ビューを読み込む度に結合処理が走るため、ビュー自体が遅くなるかも知れません。詳細は下記ドキュメントをご覧ください。
- データの抽出 - 複数の表オプションを使用するヒント
- You can now choose multiple table storage for extracts | Tableau Software
実際に両方試して、よりパフォーマンスが良い方を選ぶのがベストです。ただ、「複数の表」は機能の制限がかかるため、基本的には「単一の表」をオススメします。しかし、対象のデータが「スノーフレークスキーマ」のような、複数の正規化されたテーブルが存在するものであれば「複数の表」をオススメします。
3. ビジュアル内のマークの数を減らす
マーク数は、ビューの左下を見れば確認できます。この数が多いほどパフォーマンスは悪くなります。そのビューで確認したい要件に対して、マーク数が多すぎないか（減らせるのではないか）よく考えましょう（必要以上に細かい粒度の表示にしない）。
パフォーマンスだけでなく、アクセシビリティの観点から見ても、マーク数が多すぎるのはよくありません。下記を参考にしてマーク数を減らしましょう。
4. 未使用の列を削除 or 非表示にする
ビューに必要な列と不要な列を見直して、不要な列は削除するなり非表示にしましょう。列は少ないほどパフォーマンスは向上します。
5. 必要に応じて列を行にピボットする
Tableauは「縦持ちのデータ」に向いてます。列が日付の数だけドカドカ用意されているような場合は、Tableau Prepでピボット処理しましょう。
また、Tableau社のドキュメントにわかりやすい事例があるので、こちらも確認しましょう。
6. 行数を減らす
よくあるパターンとして「月別のデータが見たい」のに「日毎にレコードがある」というものがあります。こういう場合は月毎までデータを予め集計した方がいいです。そのビューに本当に必要な集計の粒度を熟考しましょう。当然ながら行数が少ない方がパフォーマンスは向上します。
7. 大きいクロス集計表（帳票）を作っている場合、サイズを小さくする
Tableauが一番苦手とする処理がクロス集計表（Excelのような、文字が大量に並んでいる表）の描画です。
どうしても帳票のようなビューが必要な場合、1画面に収まるサイズにしましょう。スクロールしないと全部が確認できないクロス集計表は、「本当にこのような表が必要なのか」というところから考え直したほうがいいです。
8. ODBCドライバではなく、ネイティブドライバを使用してデータソースに接続する
TableauはODBCドライバを使用することで、ネイティブ対応していないデータソースを利用することができます。
ただし、当然ながらネイティブ対応しているDB接続に比べて遅いです。ですので、ネイティブ対応しているデータソースはネイティブ機能で接続します。ODBCドライバを使わないと接続できないデータソースを使いたい場合、可能であればデータをネイティブ対応しているDB等に移した方が良い場合もあります。
9. カスタムSQLの使用を避ける
Tableauは、DBに対してTableau上で任意のクエリを投げることができます。
これも基本的に「遅い」です。TableauからDBに対して通常の接続を行うと、TableauはTableau用に最適化されたクエリを生成して使用しますが、カスタムSQLはそれを使わないため、遅くなります。
予め、必要なテーブル（そのクエリで作ることができる）は先に作っておきましょう。
10. ダッシュボードあたりのビュー数を減らす
ダッシュボードに大量のビューをぶっ込んでませんか？
本当にそんなにたくさんのビューを入れる必要がありますか？
（もしそのダッシュボードが遅いんだったら）ビューを減らしましょう。複数のダッシュボードに分散することも検討しましょう。
11. ビューに設定するフィルタの数を減らす
フィルタは便利ですが、フィルタの数だけクエリが増えて遅くなります。必要最低限にしましょう。
12. 「重要なフィルタ」「頻繁に使用されるフィルタ」はコンテキストフィルタにする
普通のフィルタ（データソースフィルタ）は、他のフィルタに関係なく、それぞれが全ての行を舐めてからフィルタリングしますが、コンテキストフィルタにしておくと、他のフィルタより先にデータをフィルタリングするため、他の通常のフィルタの処理が速くなる可能性があります。
パフォーマンスの向上 – 多数のフィルターを設定する場合や、データ ソースが大きい場合、クエリに時間がかかる場合があります。1 つまたは複数のコンテキスト フィルターを設定すると、パフォーマンスを向上させることができます。
13. LODフィルタを計算フィールドのセットに置き換える
LODは便利ですが、通常の計算より重いです（LODはネストされたSELECT文として扱われるため）。LODでフィルタをかけるより、計算を元にしたセットを作成して、それをフィルタに使用した方がいい場合があります。
注: データ ソースが大きい場合、メジャーをフィルターすると、パフォーマンスが大幅に低下します。メジャーを含むセットを作成してから、そのセットにフィルターを適用する方が、はるかに効率的な場合もあります。セットの作成の詳細については、セットの作成を参照してください。
14. パフォーマンスの問題が現れるのはTableau Desktopの時かTableau Server（Online）の時か特定する
Tableau Desktopの時だけ遅いのか、Tableau Serverの時だけ遅いのか、どっちでも遅いのか、ということを調査しましょう。
- Tableau Desktopだけ遅い？
- PCのスペックを上げる
- Tableau Serverだけ遅い？
- Tableau Serverのインフラのスペックを再検討する
- 両方？
- 他のポイントをチェックする
調査するにあたり、「パフォーマンスの記録」を使用することオススメします。
ちなみに、Tableau Desktop側だけが遅いということはほとんど無いと思われます（単純なビュー表示能力はTableau Desktopの方が高いため）。
15. コンテキストフィルタは1〜2個におさえる
Tableauのドキュメントにそのものズバリな解説があったので、引用します。
データ セットのサイズを大幅に削減できる 1 つのコンテキスト フィルターを使用する方が、多くのコンテキスト フィルターを適用するよりはるかに優れています。実際、フィルターを適用してもデータ セットのサイズが 1/10 以上削減できない場合、コンテキストにこのフィルターを追加すると、コンテキストの計算にパフォーマンス コストがかかるため、事態が悪化します。
16. ドロップダウン、ラジオボタン、スライダなどのフィルタを非列挙型フィルタに変更する
ドロップダウンやスライダーといったフィルタは、フィルタ自体のレンダリングのために、全ディメンションを読み込むクエリを実行します。これをカスタム値リストやワイルドカード一致のフィルタ（非列挙型フィルタ）に変更することで、レンダリング処理を速くすることができます（ただし、ユーザー側の利便性は損なわれるので、そこはよく考える必要があります）。
17. 「関連値のみ」を過度に使用しない
フィルタにこの設定を使用すると、フィルタに出現する値を、他のフィルタと連動させることができます。
「地域」フィルタを関西にしていると、「都道府県」フィルタに関西の府県しか表示されないようにすることができます。しかし、この場合、他のフィルタを操作すると、このフィルタ分のクエリも再度実行されます。
便利な機能なのですが、使いすぎるとクエリ数が増え、ビューが重くなります。
18. テキストフィールドの数を減らす
元記事の「text fields」が何を指しているのかイマイチわかりづらいのですが…下記のような感じで理解しておけばいいかなと。
- ビューに文字をそのまま表示する部分を減らそう…という意味
- →No.7と一緒ですが、大量の文字列のレンダリングは遅いので、できるだけビジュアライズしましょう
- 文字列型を減らそう…という意味
- →何でもかんでも文字列型にしておかずに、適切なデータ型にしましょう
19. （抽出を使わない限り）データソースにNULLまたは空白が多い状態は避ける
（ディメンションカラムに）NULLが多いとクエリが遅くなる可能性があります。DB側の設定で、あるカラムがNULLを許容している場合、そのカラムを用いた計算を実施する際に、NULLかどうかをチェックするクエリが走ります。可能であれば、DB側でそのカラムをNOT NULLにする等しておいた方がいいです。
20. データソースのレコード数が多い場合は、データブレンドの代わりにジョインを使用する
超個人的な意見ですが、複数のテーブルを統合したい場合は、基本的にジョイン（結合）でいいと思っています（データブレンドの方が良い！という場面が思い当たらない）。
結合は、キーをミスるとレコード数が増大する的な罠がありますが、それはテーブル定義をしっかり把握すればいいだけの話ですので…。
21. テーブルを結合するときは、必要なデータを生成するのに必要な、最低限のテーブルだけ結合する
まあこれはTableauに限らず、何らかのSQLクエリを作成する場合は、大体意識することだと思います。
22. 長いテキストフィールドやカーティナリティの高いフィールドでデータブレンドしない
データブレンドは、両方のテーブルにそれぞれクエリを投げて、その結果をローカルメモリ上で統合します。だからカーティナリティが高い（一意の値が多い）と、それだけ多くのメモリが必要になるため遅くなります。
23. 文字列操作を行う関数（FIND, LEFT, RIGHT, MIDなど）はできるだけ避ける
文字列関数は基本的に遅いので、Tableau Prepなどで前処理することをオススメします。また、FIND関数を使うなら、CONTAINS関数に置き換えたり、ワイルドカードフィルタを使ったりする方が良いです。
24. データベース接続時に使用するユーザーは、一時テーブルの作成および削除が可能なものを使う
TableauがRDBMSに接続する場合、セットやデータブレンド等の操作を行うときに、一時テーブルを利用します。一時テーブルの作成と削除ができる権限のユーザーで接続するようにしましょう。
25. 複雑な条件付きロジックではなく最適な日付関数を使用する
MONTH関数やYEAR関数を組み合わせて日付を計算するのではなく、DATETRUNC、DATEADD、DATEDIFFなどの日付関数を使用して計算しましょう（日付の計算は、すでに用意されている日付専用の関数を使う方が、発行されるクエリをシンプルにすることができます）。
26. 最も効率的な計算方式を使用する
その計算の目的に応じて、最適な種類の計算を選びましょう。本エントリの最初に紹介したホワイトペーパーに、計算の種類を選ぶフローチャートがあるので、それを参考にしましょう。
1. 行いたい計算は、ランク、再帰、移動計算、行間計算のいずれかか？
- Yes：表計算
- No：2へ
2. ビューに必要なデータは既に全て存在しているか？
- Yes：3へ
- No：4へ
3. ビューのレイアウト的に表計算を使っても問題ないか？
- Yes：表計算
- No：4へ
4. 計算で出したい答えの粒度は、ビューの粒度とデータの粒度のどちらに一致するか？
- ビュー：集計計算
- データ：行レベル計算
- どちらでもない：LOD
27. 最適なデータ型（計算が速いデータ型）を使用する
同じ計算でも、データ型によってスピードは変わってきます。例えば、整数とブール型は、文字列や日付より、かなり速いです（これもTableauに限らない話ですね）。
28. 最適な集計関数を使用する
集計関数（集計計算）でも、目的に応じた最適なものを選びましょう。ATTRやAVERAGEよりも、SUM、MIN、MAXの方が速いです（データソースに再問い合わせする必要がない。Tableauローカルで集計できる）。逆にCOUNTDは全集計関数の中で最も遅いものの1つなので、絶対に必要でなければ使用は避けましょう。
29. （それが絶対必要な場合）外部計算（つまりPython、R）の使用を最適化する
TableauはPythonやR言語と連携することができます。この中で複数の関数が呼び出されるようになっていると、パフォーマンスに影響があります。なるべく単一の関数の呼び出しで済むように最適化しましょう。
30. ダッシュボードには固定サイズを使用する
Tableau Server（Online）にパブリッシュした時の話ですが、動的サイズのダッシュボードの場合、閲覧者によってサイズが異なるため、それだけキャッシュのパターンが多くなり、キャッシュのヒット率が低くなります。固定サイズにすることで、閲覧者による差異を少なくし、キャッシュ効率を高めることができます。
おわりに
- ビューの目的を明確にする
- 目的に不要なデータやビューは一切入れない
- 各種計算はなるべくTableau Desktopで接続する前に済ませておく
まとめると、この3つを意識するだけでも、パフォーマンスが速くなると思います。
